Open systems and multi-vendor systems have been the recent trends of IT systems, and IT systems have grown in scale and complexity as a result of increasing number of servers and increasing storage volume. This leads not only to higher operational costs but also to frequent occurrence of system shutdown and lower quality service due to human errors. In order to prevent these problems, importance should be placed on management of configuration information of IT systems including servers, storages and applications.
A database, more specifically what is called an MDR (management data repository), is known as a device to manage configuration information of an IT system. The MDR stores operations management data of an IT system, and corresponds to a database of operations management middleware.
The operation of a data center requires operations management middleware pieces optimized for corresponding management jobs including server management, network management, service management, and asset management. The operations management middleware pieces include their respective MDRs into which configuration information about the corresponding jobs are entered. That is, one MDR manages configuration information independently of a different MDR. Accordingly, in some cases, access to MDRs should be made in respective ways, or the MDRs store configuration information in respective formats. Thus, an actual situation is that the MDRs cannot be linked with one another without human intervention.
In response, a distributed information management system has been developed that includes a database called FCMDB (federated configuration management database) in which configuration information of various types spreading over a plurality of MDRs are virtually united. As an example, the distributed information management system illustrated in FIG. 24 includes a plurality of MDRs and an FCMDB that are connected through a network. FIG. 24 is a diagram illustrating the FCMDB.
The MDRs each manage information such as that about the structure of a device existing in an IT system. The MDRs handle data of respective types and respective amounts. As a specific example, as illustrated in FIG. 14, an MDR 1 manages design information, an MDR 2 manages product information, an MDR 3 manages quality information, and an MDR 4 manages configuration information.
The FCMDB integrates configuration information about one object that is managed separately in the plurality of MDRs, and manages the integrated configuration information. More specifically, the FCMDB manages configuration items (CIs) of an IT system including a device, software and datalog, and relationships between the CIs (hereinafter simply referred to as “relationships”). In the example of FIG. 14, a CI “C” managed in the FCMDB is integrated data of design information C″ stored in the MDR 1, quality information C^ stored in the MDR 3, and configuration information C′ stored in the MDR 4.
As described, the FCMDB integrates configuration information about one object that is managed separately in the plurality of MDRs, and manages the integrated configuration information. Accordingly, in all situation of the system operation including application of patches and hardware maintenance, an operator such as a system administrator is allowed to easily understand the overall structure of the IT system by referring to the configuration information virtually integrated by the FCMDB.
A distributed FCMDB system with a plurality of FCMDBs is known that is intended to enhance scalability. In the distributed FCMDB system illustrated in FIG. 25, information in MDRs are managed separately in a plurality of FCMDBs, and the plurality of FCMDBs perform data entry and data search independently of one another. FIG. 25 is a diagram illustrating the distributed FCMDB system. In the distributed FCMDB system, for entry of data containing three CIs (C1, C2, and C3) and two relationships (R1 and R2) that are connected together, for example, C1, R2, C2, C3, and R1 are entered separately into different FCMDBs as illustrated in FIG. 25.
A data entry process in the distributed FCMDB system will be described in detail by using FIG. 26. As illustrated in FIG. 26, for entry of data containing three CIs (C1, C2 and C3) and two relationships (R1 and R2) that are connected together, the distributed FCMDB system obtains the respective hash values of the CIs and the relationships by using their respective IDs and the like. Then, by employing the respective hash values of the CIs and the relationships as their keys, the CIs and the relationships are entered separately into FCMDBs.
Referring to the example illustrated in FIG. 26, an FCMDB having accepted a request for entry calculates the hash value of C2 as “51”, and transfers the data of C2 to an FCMDB “5” in charge of the hash value “51”. Then, the FCMDB “5” in charge receives and stores the data of C2. The FCMDB “5” in charge is assigned to a CI and a relationship the hash values of which range between “51” and “59”. In the example illustrated in FIG. 26, the FCMDB “5” in charge stores C2 and R1 the hash values of which are “51” and “55”, respectively.
Furthermore, graphs each with a CI as a node and a relationship as an edge are separately stored in the distributed FCMDB system. Accordingly, when an FCMDB accepts a search request from a client terminal, a search process is performed by making communications between FCMDBs. A search process in the distributed FCMDB system will be described in detail by using FIG. 27. The search process illustrated in FIG. 27 is performed when an FCMDB 5 in the distributed FCMDB system accepts a query “% C1/&R1/%C2/&R2/%C3” as a search request. The query “% C1/&R1/%C2/&R2/%C3” is intended to search for C2 related to C1 through R1, and to search for C3 related to C2 through R2.
The FCMDB 5 having accepted the search request searches for C1 at the beginning of the query and communicates with an FCMDB 4 holding C1, thereby obtaining the ID of C1. Then, the FCMDB 5 searches for R1 that recognizes the ID of C1 as its source CI or its target CI, and obtains the ID of C2 from the FCMDB 5 itself. Next, the FCMDB 5 having accepted the search request searches for R2 that recognizes the ID of C2 as its source CI or its target CI, and communicates with an FCMDB 1 holding R2, thereby obtaining the ID of C3. The FCMDB 5 thereafter specifies an FCMDB 2 holding C3 on the basis of the ID of C3, communicates with the FCMDB 2 to obtain the information about C3. Then, the FCMDB 5 outputs the data of C3 as a result of the search to the client terminal.
The aforementioned conventional technique is disclosed, for example, in Japanese Laid-open Patent Publication No. 2009-169863 and Japanese Laid-open Patent Publication No. 2004-272369.
In the technique of the aforementioned distributed FCMDB system, CIs and relationships are entered separately into different FCMDBs. Accordingly, a search process requires trace by following relationships. This means that a search process requires frequent communications between FCMDBs, leading to lower processing speed in the search process.
A processing speed in a search process may be increased by using a cache mechanism. By way of example, a result of a query is stored in a cache memory. If the same query is accepted in a next search process, the result of the query is read from the cache memory, and is output as a result of the search. However, the same query is not always accepted, and data in FCMDBs are updated. This leads to a low hit rate of the cache memory, so that a processing speed in a search process cannot be increased.